home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir39 / ctest259.zip / COMPTEST.DOC < prev    next >
Text File  |  1993-06-09  |  69KB  |  1,125 lines

  1.      ======================= COMPTEST 2.59 ============================
  2.  
  3.      Release date: June 9, 1993
  4.  
  5.      COMPTEST is a program that determines the system configuration and
  6.      performance characteristics of PC compatible computers. COMPTEST
  7.      was designed to be fast, so most parameters are determined during
  8.      program start-up and the first page of results will come up almost
  9.      immediately. Even for slow systems like the original IBM PC the
  10.      first page will be displayed within a few seconds. There are at
  11.      most three pages with results displayed sequentially, with some
  12.      tests occurring only when the appropriate page is displayed.
  13.  
  14.      Usage: COMPTEST [file name] [/D] [/H]
  15.  
  16.      [file name]  is an optional parameter specifying a file in which
  17.                   the results displayed by COMPTEST will be saved upon
  18.                   termination of COMPTEST.
  19.  
  20.      /D           is an optional switch enabling additional messages
  21.                   that aid in debugging COMPTEST if the program should
  22.                   crash or fail to correctly determine the system
  23.                   configuration.
  24.  
  25.      /H           is a switch that prints a short help screen for COMPTEST.
  26.  
  27.  
  28.  
  29.      COMPTEST 2.59 is Copyright (c) 1988-1993 by
  30.  
  31.      Norbert Juffa
  32.      Wielandtstr. 14
  33.      7500 Karlsruhe 1
  34.      Germany
  35.  
  36.  
  37.      COMPTEST 2.59 is public domain software and is distributed with full
  38.      assembly language and Turbo Pascal 6.0 source code. You are free to
  39.      incorporate parts of the code into your own programs as long as you
  40.      don't use it in a commercial product. Please do others a favor and
  41.      always distribute the complete COMPTEST package, not only the binary.
  42.  
  43.  
  44.      If you want to notify me of bugs you discovered in COMPTEST or want
  45.      to comment on the program in any way, you can either contact me at the
  46.      address above or on Internet as JUFFA@IRA.UKA.DE
  47.  
  48.  
  49.      Revision history:
  50.  
  51.  
  52.      Changes since version 2.58
  53.  
  54. o    Detection method for Cyrix 486DCL/SLC has been changed back to method
  55.      used in COMPTEST 2.57. The detection method used in version 2.58 that
  56.      was based on checking the value in the destination register of a BSF
  57.      instruction after executing it with a source register containing zero
  58.      seems to work only with very old versions of the Intel 80486. Newer
  59.      versions of the Intel 486DX/SX show exactly the same behavior as the
  60.      486DLC/SLC. Therefore, COMPTEST 2.58 reported most 486SX as 486DLC
  61.      and 486DX as RapidCAD. Thanks to Jian Liu and David Ruggiero for
  62.      reporting this bug.
  63.  
  64. o    Experimental support to detect an Intel Pentium CPU has been added.
  65.      Detection is based on incomplete information, so Pentium detection
  66.      and measurements may not work correctly yet.
  67.  
  68.  
  69.      Changes since version 2.57:
  70.  
  71. o    Detection method for Cyrix 486DLC/SLC has been changed. The new method
  72.      does not rely on timing anymore.
  73.  
  74. o    Timing routine has been enhanced to work more reliable with fast machines.
  75.  
  76. o    Documentation file have been enhanced and updated. Minor cosmetic changes
  77.      to COMPTEST and MEMMAP programs.
  78.  
  79. o    New version of Turbo Pascal 6.0 run time library included.
  80.  
  81.  
  82.      Changes since version 2.56:
  83.  
  84. o    COMPTEST 2.56 was compiled with the wrong library. Therefore, benchmark
  85.      results for the floating-point benchmarks (Whetstone, LLL) differ from
  86.      other versions of the program. Sorry about the mistake!
  87.  
  88. o    A correction was added to the determination of coprocessor clock frequency
  89.      in the case a Cyrix 486DLC CPU is present. With a 486DLC present, the
  90.      block of FSQRTs that determines the coprocessor clock frequency is
  91.      executed faster than with the Intel 386DX as CPU, due to the improved
  92.      communication between CPU and coprocessor. The observed speedup is in
  93.      range between 4.7% and 9.7%. For simplicity, COMPTEST 2.59 uses a simple
  94.      correction that divides the computed frequency by 1.055.
  95.  
  96.  
  97.      Changes since version 2.55:
  98.  
  99. o    COMPTEST 2.55 wouldn't detect a Cyrix EMC87 if it was installed and
  100.      reported it as a Cyrix 83D87 instead. This has been fixed.
  101.  
  102. o    Correct detection of the presence and clock frequency of the Cyrix
  103.      486DLC has been tested. Note that presence of a Cyrix 486DLC may
  104.      lead to a higher clock frequency being displayed for a coprocessor,
  105.      if one is installed. Since the 486DLC has an improved handshaking
  106.      with the coprocessor, the block of FSQRT instructions used to measure
  107.      the coprocessor's clock is executed up to 10% faster and the reported
  108.      clock frequency of the coprocessor goes up accordingly.
  109.  
  110.  
  111.      Changes since version 2.54:
  112.  
  113. o    Enhanced POPAD bug detection by testing POPAD execution using 31
  114.      different initial values in the EAX register. Previously, only one
  115.      value was used, which made correct detection of the bug somewhat
  116.      unreliable.
  117.  
  118. o    Detection of the SuperMath 38700DX and 38700SX coprocessors from
  119.      Chips&Technologies have been added and successfully tested. Detection
  120.      for the Intel RapidCAD, Intel 387DX, and Cyrix 387+ has been changed
  121.      from tests depending on instruction timing to tests that rely on
  122.      certain small incompatibilities between the coprocessors.
  123.  
  124. o    When called with a filename to store the results in, COMPTEST would
  125.      fail to print the final message "COMPTEST terminated - press any key"
  126.      if either there was a error in handling the file indicated or if no
  127.      hard disk results were stored. This has been fixed.
  128.  
  129.      ======================================================================
  130.  
  131.      The following is a detailed explanation of the information provided
  132.      by COMPTEST 2.59 and the known limitations of the program.
  133.  
  134.  
  135. o    General limitations:
  136.      Correct execution of COMPTEST depends on certain hardware resources
  137.      provided by the hardware of PC compatibles. That a machine runs MS-DOS
  138.      is by itself no guarantee that COMPTEST can be run successfully, as
  139.      MS-DOS may run on machines that are not 100% compatible with industry
  140.      standard PCs. Since it directly accesses hardware components,
  141.      COMPTEST should not be run in the DOS-boxes supplied by Windows, OS/2
  142.      or similar programs. Even if it does run, some or all of the information
  143.      it provides may be wrong or misleading. For the same reason, it should
  144.      not be run on a PC emulator, e.g. SoftPC by Insignia, even if simpler
  145.      programs like the Landmark Speed Test run successfully in such an
  146.      environment.
  147.  
  148.  
  149. o    Computer type:
  150.      The specific type of an IBM compatible PC is coded into one or two
  151.      bytes in the last 16 bytes of the first MByte of the address range.
  152.      This memory is occupied by the BIOS ROM. Quiet a few values have
  153.      been defined by IBM for its PC, AT, and PS/2 computers. COMPTEST
  154.      decodes this information according to IBM's definitions and prints
  155.      the result. Ordinary 286, 386, and 486 based PCs with an ISA bus
  156.      are reported as AT compatibles.
  157.  
  158.  
  159. o    CPU Type:
  160.      COMPTEST is able to detect the following CPU types: Intel 8088,
  161.      Intel 8086, NEC V20, NEC V30, Intel 80188, Intel 80186, Intel
  162.      80286, Intel 80386DX, Intel 80386SX, Intel 80486DX, Intel 80486SX,
  163.      Intel RapidCAD, Chips&Technologies 38600DX, Cyrix 486DLC, Cyrix 486SLC.
  164.  
  165.      The Intel 80186/80188 are CPUs with integrated peripherals that
  166.      have been used in only a few PCs that were manufactured around
  167.      1982/1983. It has an extended 8086 instruction set. The Intel
  168.      RapidCAD is a replacement for a 80386/80387 combination and is
  169.      basically a 80486DX without the internal cache and with a 386 pinout.
  170.      The Chips&Technologies 38600DX is a pin compatible replacement for
  171.      the 80386DX CPU that offers some performance improvements. The
  172.      Intel 486SX is a 80486 without the FPU (floating point unit).
  173.      The Cyrix 486DLC is a CPU that is software compatible with the
  174.      486SX, but is a replacement for the 80386DX CPU. Similarly, the
  175.      Cyrix 486SLC is for use in 386SX systems.
  176.  
  177.      AMD's Am386DX, Am38DXL, Am386SX, and Am386SXL are 100% compatible
  178.      to the Intel 386DX and Intel 386SX CPUs, respectively, and are
  179.      reported as Intel 386DX and Intel 386SX, respectively, by COMPTEST.
  180.      The Intel 486DX2-50, Intel 486DX2-66, and the Intel Overdrive
  181.      processors are 486DX chips that use a clock-doubler that drives
  182.      the CPU internally at twice the speed of all other system components.
  183.      The 486DX2-50 is a replacement for the 486DX-25, while the 486DX2-66
  184.      replaces the 486DX-33. The Overdrive goes into the 487SX socket
  185.      found in many 486SX systems. These processors are all reported as
  186.      80486 processors by COMPTEST.
  187.  
  188.      To distinguish between the different CPUs and math coprocessors,
  189.      COMPTEST in most cases takes advantage of certain incompatibilities
  190.      between the chips that can be tested without using other system
  191.      resources. Only a few tests involve timing differences in the execution
  192.      of certain instructions. These depend on the correct operation of the
  193.      PC's timer chip.
  194.  
  195.      To separate the 8086, 8088, V20, V30, 80186, and 80188 CPU from
  196.      newer CPUs, the behavior of the instruction sequence PUSH SP,
  197.      POP AX is used. While after the execution of these instructions,
  198.      AX=SP on the newer processors, AX=SP-2 for the 8086..80188.
  199.  
  200.      To distinguish among the CPUs in the first group (8086..80188),
  201.      the following properties of the processors are used. The 80186/
  202.      80188 (like all newer Intel CPUs) mask off shift counts MOD 32
  203.      in shift and rotate instructions so that no more than 31 shift
  204.      steps are performed. The V20, V30, 8088, and 8008 do not mask off
  205.      shift counts and perform up to the 255 shift steps allowed by the
  206.      8-bit counter used. If a register with a non-zero contents is
  207.      shifted left with a shift count of 32, it will be cleared after
  208.      the operation on the 8086/8088 and V20/V30, while nothing will
  209.      happen on the 80186/80188, since 32 MOD 32 = 0, that is, no shifting
  210.      takes place. V20 and V30 (just like the 80186/80188 and newer CPUs
  211.      from Intel) have a PUSHA instruction that saves all general registers
  212.      on the stack. The 8086/8088 don't have this instruction, but the
  213.      execution of the PUSHA opcode acts like a JMP skipping the next
  214.      code byte. COMPTEST uses this code byte to set a flag so that
  215.      the flag is only set on V20/V30 processors. If the flag is not
  216.      set, an 8086/8086 must be present. This is verified by an additional
  217.      test that checks if the highest nibble in the flag register can be set.
  218.      This nibble is always cleared on the 8086/8088 and can not be set.
  219.  
  220.      The 8086, V30, and 80186, which have a 16-bit data bus, can be
  221.      distinguished from the 8088, V20, and 80188, which have an 8-bit data
  222.      bus through the use of self modifying code that works differently due
  223.      to the different length of the instruction prefetch queue, which has
  224.      a length of 4 bytes for the CPUs with 8-bit busses, but a length of
  225.      6 bytes for the CPUs with 16-bit busses. Modifying an instruction
  226.      five bytes ahead in the instruction stream will cause the modified
  227.      instruction to be executed by the 8-bit CPU versions, while the
  228.      original instruction will be executed on the 16-bit CPU versions,
  229.      since it was already in the prefetch queue by the time the instruction
  230.      was modified in memory.
  231.  
  232.      To tell apart the 80286 from the 80386 and 80486, an attempt is made
  233.      to change certain bits in the flag register of the CPU. While they can
  234.      be modified in the 80386 and 80486, the 80286 will not allow that to
  235.      be done. The 80486 has a new bit in its flag register that is not defined
  236.      in the 80386 and is always clear there. By attempting to toggle this
  237.      bit, it can be decided whether a 80386 or 80486 is present. The 486SX
  238.      is a 80486 without the FPU (floating point unit ~ integrated coprocessor),
  239.      so if a 486 CPU has been detected but the test for a coprocessor or
  240.      FPU fails, it can be concluded that a 486SX is present. The 80386SX
  241.      has a 16-bit data bus as compared to the 32-bit data bus of the otherwise
  242.      (almost) identical 80386DX, so 32-bit memory accesses on the 80386SX
  243.      are slower than 16-bit memory accesses since they have to be split into
  244.      two 16-bit accesses. On the 386DX, both 16-bit and 32-bit memory
  245.      accesses have the same speed, if memory operands on addresses divisible
  246.      by four are accessed. By measuring and comparing the speed of 16-bit
  247.      and 32-bit memory accesses, COMPTEST determines if a 386SX is present.
  248.      Intel and AMD both make 386DX and 386SX processors that are functionally
  249.      totally identical. However, AMD makes 386DXs that are rated for 40 MHz
  250.      and 386SXs that are rated for 33 MHz, which Intel doesn't make. So
  251.      COMPTEST could make an educated guess on what manufacturer's CPU is
  252.      used based on the clock frequency it determines. COMPTEST does without
  253.      this guess, though, and reports all AMD 386 CPUs as Intel 386DX or Intel
  254.      386SX.
  255.  
  256.      Chips and Technologies has introduced CPUs that are compatible with
  257.      the 386DX and 386SX, which are called the 83600DX and 83600SX. Also,
  258.      an 83600DX with a small internal cache has been announced called the
  259.      83605DX. While AMD uses Intel's microcode in their 386 CPUs, C&T uses
  260.      its own microcode. Therefore, the CPUs from C&T do not possess a well
  261.      known bug present in the Intel 80386. This so called POPAD bug causes
  262.      the EAX register to be trashed for a certain instruction sequence
  263.      involving the POPAD instruction. COMPTEST checks for this bug to
  264.      distinguish the C&T CPUs from Intel's 386 processors. Since I have
  265.      found that the POPAD bug can not be reliably reproduced on Intel 386SX
  266.      CPUs, COMPTEST reports all 386SX CPUs as Intel 386SX, whether a POPAD
  267.      failure occurs or not. Since C&T will not offer the 38600SX before
  268.      late in 1993, this doesn't make the CPU detection by COMPTEST less
  269.      reliable. COMPTEST will not recognize the 83605DX, but will report
  270.      it as an 83600DX. Since the reproducibility of the POPAD bug depends
  271.      somewhat on the initial value of the EAX register, COMPTEST uses 31
  272.      different values.
  273.  
  274.      The Intel RapidCAD is basically a 486 without the internal cache
  275.      that is an end user replacement for a 80386DX/80387 combination.
  276.      It is 100% software compatible with this combination and can be
  277.      detected by checking the speed of store operations from the FPU
  278.      to memory, which are executed much faster on the RapidCAD than in
  279.      any 386/387 system, regardless of the coprocessor used.
  280.  
  281.      Cyrix now offers the 486DLC and the 486SLC that are designed for
  282.      386/386SX systems. However, they are software compatible with the
  283.      Intel 486SX. Cyrix has implemented a fast array multiplier on these
  284.      chips to speed up integer multiplications, making the MUL instruction
  285.      faster than on any other CPU found in PC compatible computers.
  286.      COMPTEST detects the Cyrix 486DLC/SLC by comparing the speed of the
  287.      MUL and AAM instructions. On the 80486, the execution time for the
  288.      MUL instruction ranges from 13 to 26 clock cycles for a 16 bit
  289.      operand, while the AAM instruction executes in 15 clock cycles. So
  290.      multiplication is never significantly faster than AAM. On the Cyrix
  291.      processors, MUL takes 3 cycles with a 16 bit operand, and AAM takes
  292.      16 cylces. So on these processors MUL is several times faster than
  293.      AAM.
  294.  
  295. o    Clock frequency:
  296.      Measuring the clock frequency of the CPU is based on repeated execution
  297.      of the AAM (ASCII adjust after multiply) instruction. This instruction
  298.      takes more than 10 clock cycles to execute on all CPUs that are supported,
  299.      so there is enough time for the CPU to always keep its prefetch queue
  300.      filled, resulting in very stable timings since there is no additional
  301.      penalty for filling up the prefetch queue. Also the AAM instruction has
  302.      the advantage to execute in a fixed number of clock cycles, as opposed
  303.      to some instructions like DIV that take even longer to execute than AAM,
  304.      but whose timing depends on the input arguments. To report the clock
  305.      frequency accurately, it is absolutely important to use the correct
  306.      execution time for the AAM instruction in COMPTEST. Note that the AAM
  307.      execution time stated in the Intel manual for the 8088/8086 is not
  308.      correct. Depending on the accuracy of the oscillator that drives the
  309.      PCs timer, the reported CPU clock frequency should be accurate to within
  310.      +/- 2%. Note that for CPUs that use internal clock doubler circuits
  311.      (e.g. Intel 486DX2-50), the clock frequency displayed by COMPTEST is
  312.      the frequency at which the CPU runs internally (50 MHz in the example
  313.      cited).
  314.  
  315.  
  316. o    Bus width:
  317.      The width of the CPU data bus. This is determined by the type of the
  318.      CPU, so this is actually redundant information.
  319.  
  320.  
  321. o    Cache size:
  322.      COMPTEST is one of very few test programs that correctly determine
  323.      the cache size of first and second level CPU caches. This is very useful
  324.      if you are not sure whether the CPU cache in your computer is enabled
  325.      or functional at all. COMPTEST moves memory blocks of increasing size
  326.      and watches for sharp drops in memory throughput to determine the cache
  327.      sizes. Since the largest blocks tested have a size of 512 KB, COMPTEST
  328.      is limited in that it can *not* correctly detect CPU caches that are
  329.      bigger than 256 KB. The smallest cache size COMPTEST can determine
  330.      is 1 KB, which is the size of the internal cache on the Cyrix 486SLC
  331.      and 486DLC chips. COMPTEST's cache test strategy may be defeated if
  332.      you have defined non-cacheable areas in the first 512 KB of base memory.
  333.      Non-cacheable areas can usually be defined in the extended BIOS setups
  334.      of 386 and 486 based machines and are only necessary if you have a
  335.      write-back cache and have to ensure correct operation of memory mapped
  336.      peripherals (e.g. video memory of graphics card, Weitek coprocessor).
  337.      Usually there is no need to define a non-cacheable area in the first
  338.      512 KB of base memory. COMPTEST's cache detection usually is very
  339.      reliable, only once did it indicate a cache on a system with no CPU
  340.      cache, probably due to the mixture of page/interleave access modes
  341.      used by that system's memory. The technique used by COMPTEST to
  342.      determine cache size basically works as follows: Assume you have a
  343.      machine with a n KB CPU cache. If you read a memory block of n KB or
  344.      less twice, it will be read almost completely from the cache the
  345.      second time it is read (some data may have been thrown out by accesses
  346.      to the code of the test program, as the caches in the Intel 486 and
  347.      comptible CPUs is a unified code and data cache). However, if you
  348.      linearly read a block of 2n KB data twice, the second half of the
  349.      data block will throw out the first half of the data block that is
  350.      already in the cache. On the second pass through, accesses to the
  351.      first half of the block will result in a miss for every cache line
  352.      accessed, as the cache now contains the data from the first n KBytes
  353.      of the block. If the times to read data blocks of 2^i KBytes are
  354.      recorded, one sees a sharp increase in read time as soon as a data
  355.      block larger than the cache size is read. COMPTEST uses block moves
  356.      instead of the block reads in the example, as I have found this to
  357.      be somewhat more reliable.
  358.  
  359.  
  360. o    Maximum RAM throughput (without cache):
  361.      This is a measure of the quality of the main memory system of the
  362.      machine tested. As with all throughput numbers, higher numbers are
  363.      better. Maximum throughput is determined by executing block move
  364.      instructions moving blocks on addresses divisble by four. For processors
  365.      up to and including the 80286, 16 bit transfers are used to move the
  366.      data. For the 80386 and newer processors, 32 bit transfers are used to
  367.      correctly reflect the higher memory throughput that is possible using
  368.      instructions that can handle 32 bit data. By moving memory blocks
  369.      that are bigger than CPU caches that may be present, COMPTEST tries
  370.      to defeat the cache strategy and to measure the true speed of system
  371.      RAM as if no cache(s) were present. However, this technique can back-
  372.      fire so the values given by COMPTEST for RAM throughput without cache
  373.      may be different from those that COMPTEST determines if the cache(s)
  374.      are physically disabled (usually possible through the BIOS setup). The
  375.      value reported by COMPTEST for RAM throughput without cache is really
  376.      the memory throughput with the maximum possible number of cache misses.
  377.      With a decent cache controller, the memory access speed in case of
  378.      a cache miss is the same as if no cache were present at all. However,
  379.      some cache controllers impose an additional overhead on such a memory
  380.      access that may be as large as 40 clock cycles per cache line loaded,
  381.      as opposed to 3-4 clocks for a good cache controller. In these cases,
  382.      COMPTEST reports up to 6 wait states or even more for RAM access
  383.      without cache. Even if COMPTEST does not report the correct value
  384.      for the RAM throughput in these cases, it is still a valuable indicator
  385.      of the quality of the cache/memory subsystem implementation. The
  386.      higher the throughput reported the better does the system perform. On
  387.      systems with no CPU cache, COMPTEST reliably measures the true throughput
  388.      of the system RAM. Based on the measured throughput as compared to
  389.      the maximum throughput for the detected CPU, COMPTEST also computes
  390.      the equivalent number of wait states. This is not an integral number
  391.      due to the fact that the number of wait states is usually not the
  392.      same for every memory access. COMPTEST reports the *average* number
  393.      of wait states needed. With wait states, lower numbers are better.
  394.      Older 80286 based systems going faster than 10 MHz usually have at
  395.      least 0.6-0.7 wait states but on a recently tested 80286 system running
  396.      at 16 MHz, COMPTEST reported 0.1 wait states, which reflects the state
  397.      of the art in memory system design. 80386DX and 80486 based systems
  398.      typically have no less than 1.6 wait states. A brand-new 386SX system
  399.      based on the Am386SX-33 had only 0.3 wait states, though. There are
  400.      machines that use fast SRAM for the 640 KB base memory that doesn't
  401.      force the CPU to insert wait states when accessing this memory. Please
  402.      note that systems using clock doubled chips will often report more
  403.      wait states than systems in which the CPU runs at the same speed as
  404.      the other system components including the memory subsystem. In systems
  405.      with a clock doubled CPU, memory always looks slow to the CPU, as one
  406.      clock cycle on the memory data bus equals two internal CPU clock cycles.
  407.      Since COMPTEST reports waits states measured in CPU clock cycles, one
  408.      will see the wait states reported double when changing from a 486DX-33
  409.      to a 486DX2-66 on the same motherboard. For example, a board for which
  410.      COMPTEST reported 2.6 wait states when run with a 486-33 CPU will have
  411.      5.2 wait states reported after changing to a 486DX2-66 CPU. Reporting
  412.      the wait states measured in internal CPU clock cycles is well justified,
  413.      as the number of wait states tell the user something about the relative
  414.      speed of the memory compared to the speed of the CPU. Clearly, a memory
  415.      subsystem running at 33 MHz is more adequate for a CPU running at 33 MHz
  416.      than for one running at 66 MHz. The RAM throughput measured by COMPTEST
  417.      refers only to base memory (first 640 KB of memory or less).
  418.  
  419.  
  420. o    Cache Throughput:
  421.      This information is only reported if COMPTEST has found a CPU cache
  422.      in the machine. As with memory throughput, higher numbers are better.
  423.      Cache throughput is determined by performing block moves on addresses
  424.      divisible by four within the cache memory using the CPU's MOVS
  425.      instruction with the maximum data width available. If two levels of
  426.      cache are present in the system (e.g. a 80486 system with an external
  427.      cache of 256 KB and the 8 KB of internal cache in the 80486), the
  428.      throughput for both is reported. You will see a performance drop
  429.      going down the memory hierarchy. First level caches usually run with
  430.      no wait states, that is with the full speed supported by the CPU.
  431.      The second level cache has less throughput than the first level cache,
  432.      but is several times larger. The system memory is even slower than
  433.      the second level cache but much bigger. The cache throughput rates
  434.      reported by COMPTEST usually are accurate indicators of the cache
  435.      performance. Write-back caches may have higher throughput rates
  436.      reported than write-through caches, as the block move performs reads
  437.      and writes. However, write-back caches also show higher performance
  438.      when used with real applications, so the higher performance indicated
  439.      by COMPTEST is probably justified.
  440.  
  441.  
  442. o    System memory:
  443.      System memory here refers to the base memory within the first megabyte
  444.      of the address space and below the start of a graphics adapter's
  445.      display memory. COMPTEST searches for RAM in small steps from the
  446.      bottom to the top of the address space until it reaches a graphics
  447.      adapter or no more contiguous RAM is found. Note that this value
  448.      can be larger than the usual 640 KB. For example, on systems that
  449.      have only a CGA, system memory could be expanded up to address B8000h
  450.      for a total of 736 KBytes of system memory. Similarly, system memory
  451.      could be expanded to 704 KBytes on a system using a monochrome
  452.      Hercules card. There are special memory cards that allow such extensions.
  453.      Also, utilities such as the VIDRAM program included with Quarterdeck's
  454.      QEMM memory manager can expand the base memory by either using part
  455.      of a VGA's or EGA's display memory as system memory or mapping
  456.      extended memory into this range, and disabling part of the EGA/VGA's
  457.      capabilities to make basically a CGA out of them.
  458.  
  459.  
  460. o    Memory available to DOS:
  461.      This is the amount of system memory (base memory) that the BIOS
  462.      reports to DOS. The BIOS determines the amount of system memory
  463.      during a cold boot and stores the result in its data block which
  464.      starts at address 400h. Several utility programs that extend the
  465.      system memory above 640 KB, such as the VIDRAM program that comes
  466.      with Quarterdeck's QEMM memory manager, manipulate this value to
  467.      reflect the greater amount of memory now available to DOS. Note
  468.      that the value reported by COMPTEST does not include DOS memory
  469.      in UMBs created by MS-DOS 5.0 or similar programs. This test is
  470.      a bit out of date and could be updated to support the new features
  471.      of the latest DOS versions.
  472.  
  473.  
  474. o    Memory permanently used by DOS and TSRs:
  475.      As the previous test, this one is outdated in that it doesn't take
  476.      into consideration the state of the art with regard to DOS memory
  477.      management. All memory below the address at which COMPTEST is loaded
  478.      is assumed to be unavailable to DOS. Device drivers and TSRs that are
  479.      loaded high are not included into the amount of memory reported. Use
  480.      the program MEMMAP also included in the COMPTEST archive file to get
  481.      a detailed list of memory blocks allocated to DOS and TSRs.
  482.  
  483.  
  484. o    Extended memory (INT 15h throughput):
  485.      Extended memory is that part of a PC's memory that is above the
  486.      first megabyte of the CPU's address space. It can be available only
  487.      on those computers that have an 80286 or newer CPU. Except for the
  488.      first 64 KB block of extended memory, which is called HMA (high
  489.      memory area), it can only be accessed in the protected mode of
  490.      these processors. COMPTEST reports the amount of extended memory
  491.      as determined by the system BIOS during a cold boot. This value is
  492.      stored in the CMOS RAM of the real time clock of AT type machines.
  493.      On newer PCs, this CMOS has been physically incorporated into the
  494.      chip set that contains most of the discrete logic of older PCs in
  495.      two or three chips. COMPTEST reads the amount of extended memory
  496.      directly from the CMOS RAM. Note that the sum of base memory
  497.      and extended memory may not add up to the total memory installed
  498.      in the machine, as some of this memory may be used to shadow the
  499.      BIOS ROM and/or ROM extensions (e.g. VGA BIOS) and is therefore
  500.      unavailable for other purposes. Shadowing means that the code in
  501.      the ROMs is copied to RAM during a cold boot and that this RAM is
  502.      mapped to the same address as the shadowed ROM. Since ROMs are slow,
  503.      code in the ROMs (e.g. BIOS) executes slowly and can be sped up a
  504.      lot by shadowing. Extended memory can be accessed in several ways.
  505.      One way is to use the services of a XMS (extended memory specification)
  506.      driver such as HIMEM.SYS. This, however, requires such a driver to
  507.      be loaded. There are also functions provided by the BIOS via INT 15h
  508.      to access extended memory. COMPTEST uses these to copy a block of
  509.      memory from extended memory to the base memory below 640 KB and
  510.      determines the transfer rate (throughput) by measuring the time it takes
  511.      to copy the block. Using a memory manager such as QEMM usually causes
  512.      the INT 15h functions to be mapped to the appropriate XMS calls, so
  513.      the INT 15h throughput value may differ significantly depending on
  514.      whether a memory manager is loaded or not. Not all BIOSes use 32-bit
  515.      transfers for block copies from/to extended memory when it is
  516.      possible (that is, on 386 and 486 based machines), so the INT 15h
  517.      throughput from extended memory may be only half of the normal system
  518.      memory throughput. Also, access to extended memory usually requires the
  519.      CPU to be switched to protected mode and back, which causes considerable
  520.      overhead when it is not done via the fast methods provided by most
  521.      386 and 486 chip sets, but uses the traditional method which involves
  522.      using the keyboard controller.
  523.  
  524.  
  525. o    Expanded Memory:
  526.      Expanded Memory, specified in the EMS (expanded memory specification),
  527.      was originally designed to provide 8086 and 8088 based computers, which
  528.      have only a one MByte address space, with up to 32 MBytes of memory.
  529.      The LIM (Lotus, Intel, Microsoft)-EMS is a standardized application
  530.      interface that permits several implementation techniques. Memory cards
  531.      which support expanded memory in hardware use sort of a bank switching
  532.      technique. Up to four blocks of 16 KBytes each can be mapped into a
  533.      contiguous 64 KB region in the address range C8000h-E0000h. This region
  534.      is called the EMS page frame. The memory on such EMS cards can not be
  535.      accessed as fast as the system memory on the motherboard in most
  536.      computers, since the data has to travel over the relatively slow ISA
  537.      bus. On the 386 and 486 based computers mostly used nowadays, expanded
  538.      memory is usually provided by a memory manager like 386MAX, QEMM, or
  539.      EMM386 that manages part of the extended memory (memory above the first
  540.      MByte of the address space) as expanded memory. These programs use the
  541.      MMU (memory management unit) built into these CPUs to map memory blocks
  542.      from the extended memory to the EMS page frame. There are also programs
  543.      that use the hard disk to provide the storage for expanded memory.
  544.  
  545.      COMPTEST tries to detect an EMS driver in the system. If it finds one,
  546.      it will question the driver for the total EMS memory provided by it,
  547.      the start address of the EMS page frame and the EMS version number with
  548.      which the EMS driver complies. The current version of EMS is 4.0, which
  549.      defines additional services over the previous version 3.2. COMPTEST does
  550.      not detect a memory card with hardware support for EMS if the EMS driver
  551.      for the card has not been loaded. COMPTEST determines the throughput from
  552.      EMS memory by reserving a EMS-page, mapping it into the page frame and
  553.      doing a block copy from the mapped-in page.
  554.  
  555.      Note that the total amount of memory available to programs that can
  556.      make use of expanded and extended memory may well be lower than the
  557.      sum of the extended memory and the expanded memory, as some of the
  558.      extended memory physically present in the machine and reported by
  559.      COMPTEST may have been logically converted to EMS memory by an EMS
  560.      driver. For example, the QEMM 6.0 memory manager provides extended
  561.      memory according to XMS and expanded memory via a built-in EMS driver,
  562.      and satisfies memory allocation request from a common pool for both
  563.      types of memory. So for a machine with 8 MBytes of physical memory it
  564.      may report 7 MBytes of EMS and 7 Mbytes of extended memory.
  565.  
  566.  
  567. o    other RAM:
  568.      COMPTEST tries to find additional RAM between the end of the graphics
  569.      card's display memory and the start of the BIOS ROM. This RAM may be
  570.      provided by special memory cards or by some chips sets like NEAT that
  571.      can map memory to this region physically. It can also be provided by
  572.      386 memory managers, that use the processor's MMU (memory management unit)
  573.      to logically map memory to this region. The latest DOS versions (e.g.
  574.      MS-DOS 5.0) can use such memory in the form of UMBs (upper memory
  575.      blocks). COMPTEST may also find RAM that is present on network adapters
  576.      or certain hard disk controllers. In such cases, COMPTEST may report
  577.      numerous very short RAM blocks. If the length of these blocks is below
  578.      one KByte, COMPTEST prints the size as 0 KB. The memory found on network
  579.      adapters and hard disk controllers is of course not available to DOS.
  580.      Rather, these adapters use the RAM for buffers or to hold certain
  581.      variables. COMPTEST does not scan the address space above the display
  582.      memory byte by byte to find RAM. Rather it tests every 256th byte if
  583.      it is in RAM. The byte is tested by writing two different values to
  584.      it and checking if both can be reliably read back.
  585.  
  586.  
  587. o    BIOS-extensions:
  588.      COMPTEST searches for BIOS-extensions such as a VGA-BIOS or hard disk
  589.      BIOS between the end of the graphic adapter's display memory and the
  590.      start of the main BIOS-ROM. COMPTEST checks in steps of 256 bytes if
  591.      the next two bytes read 55h, AAh, which is the common ID with which
  592.      all BIOS extensions start. If the sequence 55h, AAh is found, COMPTEST
  593.      reads the next byte, which stores the length of the BIOS-ROM measured
  594.      in 0.5 KByte blocks, if a BIOS-extension is indeed present. All bytes
  595.      in the memory region specified by the length byte are summed up. If
  596.      the 8 lowest bits of the sum are found to be all zero, a valid BIOS
  597.      extension has been found. COMPTEST then tries to determine if the BIOS
  598.      extension found is a hard disk BIOS or an EGA/VGA BIOS and displays
  599.      that additional information where applicable. Note that the same block
  600.      of memory can be displayed as both, a BIOS extension and extra RAM.
  601.      This usually indicates that BIOS shadowing is being used and that
  602.      the shadowed BIOS has not been write protected.
  603.  
  604.  
  605. o    parallel ports:
  606.      COMPTEST prints the number of parallel ports as reported in the
  607.      BIOS's equipment byte.
  608.  
  609.  
  610. o    serial ports:
  611.      PCs are commonly prepared to manage up to four serial ports in the
  612.      system. The BIOS checks for serial ports installed during a cold
  613.      boot and stores the number of serial ports found in the BIOS' data
  614.      area (starting at address 400h). It also determines the start address
  615.      for the block of IO-ports each serial port occupies. COMPTEST evaluates
  616.      this information. It also tests for serial ports (UARTs = universal
  617.      asynchronous receiver transmitter) itself, searching the four
  618.      standardized IO starting addresses used in PCs (3F8h, 2F8h, 3E8h, 2E8h).
  619.      First it tries to establish whether a UART is present at the specified
  620.      address by trying to switch on the loop back feature of the UART and
  621.      then transferring a byte through the loop. If this test passes, COMPTEST
  622.      assumes that a UART is present, since it is highly unlikely that any
  623.      other device would correspond to the same sequence of instructions in
  624.      the same manner. COMPTEST then tries to find out whether the UART chip
  625.      used is a 8250, 16450, 16550, or 16550A. The 8250 is the UART chip used
  626.      in PC compatibles. The 16450 is the successor to the 8250 chip. It
  627.      supports transfers at higher baud rates than the 8250. It also features
  628.      a scratch register that the 8250 does not have. By trying to store
  629.      values in the scratch register and read them back, COMPTEST determines
  630.      whether a 8250 or 16450 is in the system. The 82450 is the same chip
  631.      as the 16450 produced by a different manufacturer and is reported as
  632.      a 16450 by COMPTEST. The 16550 is a 16450 with added send and receive
  633.      FIFO buffers. This makes for more reliable communication and higher
  634.      effective transfer rates in interrupt driven serial communication. The
  635.      original 16550 had a bug that was fixed in the 16550A. The 16550 has
  636.      two status bits that reflect the status of the send/receive FIFOs. On
  637.      the 16550 only one of these bits works correctly, while on the 16550A,
  638.      both of them perform as expected. This is used by COMPTEST to distinguish
  639.      between the two chips.
  640.  
  641.  
  642. o    mathematical coprocessor:
  643.      COMPTEST checks if a 80x87 mathematical coprocessor is present. If
  644.      one is found, it does a detailed check on the type of coprocessor
  645.      installed. It can determine the presence of the Intel 8087, Intel
  646.      80187, Intel 80287, Intel 287XL, Intel 80387, Intel 387DX, Intel
  647.      387SX, Intel RapidCAD, Cyrix 82S87, Cyrix 83S87, Cyrix 83D87, Cyrix
  648.      387+, Cyrix EMC87, IIT 2C87, IIT 3C87, IIT 3C87SX, ULSI 83S87, ULSI
  649.      83C87, C&T 38700DX, C&T 38700SX and coprocessor emulators using INT 7
  650.      for emulation. The Cyrix EMC87 is a 387DX compatible coprocessor that
  651.      also provides a memory mapped mode and goes into the EMC socket (found
  652.      in most 386 based machines) that was originally designed for the Weitek
  653.      coprocessors. Correct detection of most, but not all, of the chips
  654.      mentioned has been tested. COMPTEST also tries to determine the presence
  655.      of a Weitek Abacus 3167 or 4167 coprocessor by checking the BIOS'
  656.      equipment status for a set Weitek bit. However, on most systems, this
  657.      bit is only set if the Weitek coprocessor has been registered in the
  658.      BIOS extended setup by the user, so it is not very reliable. COMPTEST
  659.      does not check for physical presence of a Weitek coprocessor.
  660.  
  661.      COMPTEST takes advantage of the fact that 80x87 coprocessor instructions
  662.      are ignored in systems with no coprocessor. It executes instructions
  663.      that store the default status and control words of a coprocessor to
  664.      memory. If no coprocessor is present, nothing gets stored in these
  665.      memory locations. If the expected values are stored in these locations
  666.      COMPTEST knows that a coprocessor is present.
  667.  
  668.      If a coprocessor has been found, COMPTEST tries to detect into which
  669.      of the following four groups it belongs: emulator via INT 7, 80486,
  670.      8087/80287, all other coprocessors. If the emulation bit in the
  671.      machine status word of a 286 or 386 CPU is set, COMPTEST assumes that
  672.      the 'coprocessor' found is actually an emulator that emulates coprocessor
  673.      instructions via the INT 7 trap. If the CPU was found to be an Intel
  674.      80486, COMPTEST knows that the coprocessor found is the FPU on this
  675.      chip. The Intel 8087 and 80287 were designed before the IEEE-754 Standard
  676.      for Binary Floating-Point Arithmetic was finally accepted in 1985. As
  677.      opposed to all newer coprocessors, they implemented certain features
  678.      no longer supported in the final form of the standard. One of these
  679.      features was that they had two modes for handling infinities. In one
  680.      mode, infinities were signed, in the other, all infinities did not
  681.      carry a sign and were the same. COMPTEST uses this to separate the 8087
  682.      and 80287 from other coprocessors. It generates an infinity by means
  683.      of a division by zero, duplicates that infinity, changes the sign of
  684.      the infinity and then compared the two values. On the 8087 and 80287,
  685.      they will be reported to be identical, while on all other coprocessors,
  686.      the are reported as different due to the different sign. This enables
  687.      COMPTEST to distinguish the Intel 80287 from the 287XL and coprocessors
  688.      compatible with the latter, such as Cyrix 82S87 and IIT 2C87. It also
  689.      makes it possible to find out whether a 386 based system uses the 287
  690.      or a 387 as the coprocessor.
  691.  
  692.      The 287 and 387 compatible coprocessors from different manufacturers
  693.      can be told apart by certain incompatibilities:
  694.      The IIT coprocessors do not support denormal numbers in the coprocessor's
  695.      internal format, while all other coprocessors do. COMPTEST tests for
  696.      the IIT coprocessors by loading an extended precision denormal and
  697.      adding that number to itself. On all coprocessors except the ones
  698.      from IIT, this causes the denormal exception to be raised. Since the
  699.      result is flushed to zero on the IIT coprocessors, the denormal exception
  700.      is not raised.
  701.      The ULSI coprocessors do not support the rounding control feature of
  702.      the other coprocessors. They compute all results in extended precision.
  703.      To test for ULSI coprocessors, COMPTEST sets the precision control
  704.      to 53 bits and then multiplies two numbers whose product can be
  705.      represented exactly in the 64 mantissa bits of the extended precision
  706.      format, but not in 53 mantissa bits. Therefore, the precision exception
  707.      is raised on all coprocessors except the ones from ULSI.
  708.      In the Cyrix coprocessors, several small bugs present in the Intel
  709.      coprocessors have been fixed. One of them deals with the operation
  710.      on NaNs. Intel's requirements state that an instruction that operates
  711.      on two NaNs should return the larger of the two NaNs. However, if both
  712.      NaNs have the same absolute value but different sign, Intel's coprocessors
  713.      erroneously return the negative (and therefore smaller) NaN. The Cyrix
  714.      coprocessors return the correct result in these cases. COMPTEST uses
  715.      the FPATAN instruction to perform the test described. The successor
  716.      to the 83D87 from Cyrix is the 387+. This is a "Europe-only" name, in
  717.      other parts of the world, the new coprocessor is sold under the old
  718.      name 83D87. The 387+ can be told apart from the 83D87 because of its
  719.      extended argument range for the FYL2XP1 instruction. While the range
  720.      for this instruction is restricted to -sqrt(2)/2..sqrt(2)/2 on all
  721.      other 80x87 compatibles, it is unrestricted in the 387+. COMPTEST
  722.      computes FYL2XP1 (1.0) and tests if the correct result (1.0) is returned.
  723.      The Cyrix EMC87 can be told apart from other Cyrix coprocessors since
  724.      the most significant bit of its control word can be written.
  725.      The Intel 80387 exists in two versions. The newer one is called 387DX
  726.      and provides about 20% more performance. One difference between these
  727.      chips is what they get for the exponent when doing an FXTRACT of -1.0.
  728.      While the older 80387 gets -0.0 as the answer, the newer 387DX gets
  729.      +0.0. This difference is used by COMPTEST to decide which Intel 80387
  730.      is in the machine.
  731.      The coprocessors from Chips and Technologies are detected by the result
  732.      they return for F2XM1 (pi). Note that F2XM1 is only defined for arguments
  733.      in the interval -1..1. The C&T 38700 coprocessor returns pi/2 when F2XM1
  734.      is called with an argument of pi. The Cyrix coprocessors return the same
  735.      result, but are never submitted to the test for the C&T coprocessors.
  736.      The Intel RapidCAD behaves like a 386/387 combination. One of the few
  737.      differences is the way in which the value BCD INDEFINITE is stored.
  738.      While the Intel 80387 and 387DX store it as FFFF 8000000000000000, the
  739.      RapidCAD and the Intel 80486 store it as FFFF C000000000000000. This
  740.      difference is used by COMPTEST to detect the RapidCAD chip.
  741.  
  742.      COMPTEST measures the clock speed of the coprocessor by measuring the
  743.      time it takes to execute a block of FSQRT instructions. This instruction
  744.      was picked since it has a very stable execution time that varies
  745.      only minimally and has a sufficiently high execution time. However,
  746.      the execution time of coprocessor instructions in 286 and 386 systems
  747.      may vary by a few clock cycles, depending on the chip set used. Also,
  748.      in some systems, the CPU and the coprocessor run asynchronously,
  749.      causing the execution time of coprocessor instructions to vary even
  750.      more, since in 286 and 386 systems the CPU has to fetch the instructions
  751.      and operands for the coprocessor.
  752.  
  753.  
  754. o    mouse:
  755.      COMPTEST tries to detect the presence of a mouse driver, not if a
  756.      mouse if physically hooked up to the PC. It calls a specific mouse
  757.      driver function that returns the information which mouse button has
  758.      been pressed. This has the advantage that the mouse driver's status
  759.      is not changed.
  760.  
  761.  
  762. o    games adapter:
  763.      COMPTEST tries to determine the presence of a games adapter (used
  764.      to hook up up to two analog joysticks to the PC). This test has two
  765.      stages: In the first stage COMPTEST asks the BIOS if a games adapter
  766.      is present, in the second stage it tries to access the games adapters
  767.      registers. Unfortunately, both methods seem to be highly unreliable,
  768.      as COMPTEST usually reports that no games adapter could be found,
  769.      even if one is installed.
  770.  
  771.  
  772. o    DOS drives:
  773.      COMPTEST determines the number of DOS drives by trying to set the
  774.      default drive to DOS drives 0 to 8, and returns all those drives
  775.      as valid DOS drives that can be used as DOS default drive. Note
  776.      that this limits the number of DOS drives that COMPTEST recognizes
  777.      to a maximum of nine drives. This can easily be expanded by some
  778.      changes to the source code.
  779.  
  780. o    floppy drives:
  781.      COMPTEST reports the number of floppy drives as reported in the BIOS
  782.      equipment flag. In AT compatible systems, the type of each floppy
  783.      drive is taken from the drive information found in the CMOS RAM in
  784.      the real time clock. In modern system, this RAM is now part of the
  785.      system's chip set.
  786.  
  787.  
  788. o    hard disks:
  789.      COMPTEST recognizes up to four hard disks. For each drive, it calls
  790.      the 'drive ready' status function of the BIOS. Every drive that
  791.      returns the 'ready' condition is included into the final tally.
  792.      Some removable hard disks, such as Tandon's data packs, that require
  793.      special drivers to hook into the DOS file system, are not recognized
  794.      as hard disks by COMPTEST.
  795.  
  796.  
  797. o    graphics card:
  798.      COMPTEST reports only one graphics card in the system, even if two
  799.      are installed (e.g. EGA and Hercules). It recognizes MDA and CGA
  800.      (found in the original IBM-PC), EGA (introduced with the IBM-AT),
  801.      MCGA and VGA (introduced with IBM's PS/2), also the monochrome
  802.      Hercules card and IBM's PGA. No attempt is made to distinguish
  803.      between the many different chip sets used in today's VGAs (e.g.
  804.      TVGA, Tseng ET4000, Video 7). COMPTEST will also not recognize the
  805.      Hercules RAMFont and Hercules InColor cards, 8514/A, Tiga cards or
  806.      other accelerated graphics cards. COMPTEST detects most of the
  807.      graphics cards it recognizes by making call's to certain functions
  808.      in their BIOS. For EGA cards, it also reports the amount of memory
  809.      on the adapter as reported by the EGA-BIOS.
  810.  
  811.  
  812. o    Video-RAM wait states:
  813.      The CPU usually can not access the display memory on a graphics card
  814.      at full speed due to a number of reasons. As the CRT controller on the
  815.      graphics adapter has to read out the display memory to generate the
  816.      CRT signals and the DRAM found on most graphics cards does not allow
  817.      simultaneous access from the CPU and the CRT controller, the CPU may
  818.      have to wait until the CRT controller has finished its access to a
  819.      particular part of display memory. Second, data transferred to/from
  820.      a graphics card has to travel over the PCs system bus, which has a
  821.      limited throughput that is much smaller than the memory bandwidth of
  822.      the CPU, thus slowing down the average memory access over the bus. The
  823.      ISA bus found in most PCs is particularly slow, while the MCA and
  824.      EISA busses provide more bandwidth. To overcome this problem, some
  825.      manufacturers have chosen to integrate the graphics adapter on the
  826.      mother board or couple the graphics adapter more closely to the CPU
  827.      using a technique called local bus. Local busses are direct extensions
  828.      of the CPU's busses. They usually run at the full speed of the system
  829.      and provide high bandwidth, but can only drive a limited number of
  830.      cards. A popular form of the local bus concept is the VESA local bus
  831.      (VLB), for which numerous graphics cards are now available. Third,
  832.      for fast machines, the speed of the DRAM chips on many graphics card
  833.      (60-70 ns at best) is to slow to allow zero wait state operation of
  834.      video memory accesses. This is the same problem that affects memory
  835.      accesses to the system RAM in these machines. Use of VRAM eases the
  836.      problem somewhat, so all fast graphics cards now use VRAM. Fourth,
  837.      the bus interface used by the graphic card's chip set may introduce
  838.      additional slow down due to the physical organization of the display
  839.      memory (e.g. remapping word accesses to byte accesses). End users can
  840.      influence the raw video throughput (and thereby the number of wait
  841.      states) by selecting a graphics card with a fast chip set and by
  842.      configuring their system to use as high a bus speed as possible.
  843.      Typical numbers for video-RAM wait states are 1 wait state per MHz
  844.      CPU clock frequency for Hercules cards, ~15 wait states for EGA cards,
  845.      and as low as 7 wait states for fast VGA cards (e.g. those using the
  846.      ET4000 chip set). Note that on 486-DX2 system, the number of wait
  847.      states is usually higher since the whole system runs at half the
  848.      speed of the CPU. To measure wait states for video-RAM accesses,
  849.      COMPTEST stores a block of data to the video adapter and measures
  850.      the time to do that. This time is then compared to the time it would
  851.      take to store this data in zero wait state memory. From these values
  852.      the number of wait states is computed. COMPTEST uses the memory at
  853.      address B0000h for monochrome modes and B8000h for color modes for
  854.      this test. On some graphics cards, the memory access at these addresses
  855.      may have a higher number of wait states than in other parts of the
  856.      screen memory (e.g. the memory at A0000h used by high resolution
  857.      graphics modes of EGA/VGA cards). There is also a PD program
  858.      called VIDSPEED that uses a technique similar to COMPTEST's to
  859.      report video-RAM throughput and vertical and horizontal retrace
  860.      frequencies. Note that for graphics cards with accelerator chips,
  861.      the speed with which the CPU can access the RAM on the graphics card
  862.      is not a good indicator of the Windows, OS/2, or X-Windows performance,
  863.      as many operations on the cards are performed on the card itself.
  864.  
  865.  
  866. o    Speed of video output via BIOS:
  867.      The speed is given in characters output per second as measured for
  868.      function #9 of the video BIOS (write character with attribute). Note
  869.      that there are other video-BIOS functions that write characters
  870.      to the screen, that may be faster or slower than the function to
  871.      be chosen for COMPTEST. For these reasons, it is hard to compare
  872.      the output speed determined by COMPTEST with other system diagnostic
  873.      programs such as DiagSoft's PowerMeter. As this test heavily exercises
  874.      code in the video-BIOS, there may be huge performance differences
  875.      between a shadowed and a non-shadowed BIOS. BIOS shadowing means
  876.      that the BIOS code is copied from slow ROMs to fast RAM for faster
  877.      execution at system start up. This is an option in most 286/386/486
  878.      based systems that operate at more than 10 MHz. BIOS throughput drops
  879.      due to the use of the 386 memory managers, since these programs
  880.      intercept all interrupts and therefore introduce a considerable
  881.      overhead into the execution of BIOS interrupts. There may also be
  882.      TSRs that hook the video BIOS interrupt and cause BIOS throughput to
  883.      drop even further. The typical BIOS throughput in fast 386 and 486
  884.      systems usually exceeds 100,000 characters per second. Due to the
  885.      trend to GUIs (graphical user interfaces), the output speed of the
  886.      BIOS has lost its earlier importance. Most programs do not even
  887.      use the BIOS for character based output, but rather write to the
  888.      screen directly. Note that scrolling may reduce the output speed
  889.      significantly and is not included in the BIOS throughput test by
  890.      COMPTEST.
  891.  
  892.  
  893. o    Speed of video output via DOS:
  894.      The speed is given in characters output per second as measured for
  895.      the DOS functions #9 (print string). Note that the DOS file functions
  896.      can also be used to print to the screen and that the output speed
  897.      for these function may differ from the output speed reported. Also,
  898.      the output speed may depend on the string length of the string to
  899.      be printed due to varying amount of overhead while calling DOS. Since
  900.      an ANSI driver usually causes a much slower DOS video output due to
  901.      the need of the driver to check the output stream for interpretable
  902.      sequences, COMPTEST states if the speed shown refers to the output
  903.      speed with or without an ANSI driver present. To check for an ANSI
  904.      driver, COMPTEST prints an ANSI ESC sequence that causes an ANSI
  905.      driver to report the cursor position by inserting the result string
  906.      into the keyboard buffer. COMPTEST then checks if this information
  907.      has arrived in the keyboard buffer and assumes the presence of an
  908.      ANSI device driver if it finds the information in the keyboard buffer.
  909.      Besides the use of an ANSI or similar terminal driver (e.g. EANSI,
  910.      NANSI), the use of a 386 memory manager such a 386MAX, QEMM, or EMM386
  911.      can slow down DOS video throughput as the use of these programs causes
  912.      a higher overhead in the interrupt calls used in the code that prints
  913.      to the screen.
  914.  
  915.  
  916. o    DOS version:
  917.      Shows the DOS version as reported by a call to the DOSGetVersion
  918.      function of MS-DOS. For version 5.0 or later, this may not be
  919.      the true DOS version, since the DOS version number reported to
  920.      an application can be manipulated using the SETVER utility of DOS.
  921.  
  922.  
  923. o    Standard benchmarks:
  924.      COMPTEST uses three widely known standard benchmarks to provide some
  925.      measurements of system performance. Since results for these benchmarks
  926.      depend not only on the speed of the hardware, but also on the code
  927.      quality of the compiler, only the relative performance to the original
  928.      IBM PC displayed by COMPTEST is really significant. The reference
  929.      numbers used in COMPTEST were determined using my own fast replacement
  930.      for Turbo Pascal 6.0's run-time library (available as TPL60N19.ZIP
  931.      from garbo.uwasa.fi and additional ftp sites). The compiler switch
  932.      settings were the same as those found in the source code of COMPTEST
  933.      2.59. If you use another compiler, e.g. Stony Brook Pascal+, which is
  934.      an optimizing compiler mostly compatible with TP 6.0, or use other
  935.      switch settings, you *must* determine new reference values for the
  936.      IBM PC if the PC relative performance numbers are to be of any use.
  937.  
  938.  
  939. o    Dhrystones:
  940.      The results of running the Dhrystone benchmark, a synthetic benchmark
  941.      that is supposedly representative of integer applications. Note that
  942.      Dhrystone performance depends on the hardware as much as on the
  943.      compiler. Therefore, Dhrystone numbers by other system test programs
  944.      may be higher or lower as those reported by COMPTEST, depending on
  945.      whether or not they were compiled with an optimizing compiler or run
  946.      as a 16-bit or a 32-bit program. There are different versions of
  947.      Dhrystone, the version used here (2.1) is the latest available from
  948.      the author of the benchmark, Reinhold Weicker. The Dhrystone code
  949.      fits well into a rather small cache (8 KB will be sufficient), so
  950.      for systems with CPU caches it tests only CPU performance, *not*
  951.      the performance of the memory system. To make the Dhrystone performance
  952.      as determined by COMPTEST useful, the relative performance as
  953.      compared to the original IBM-PC is given.
  954.  
  955.  
  956. o    Whetstones:
  957.      The results of running the Whetstone benchmark, a synthetic benchmark
  958.      that stresses mainly floating point performance, including trans-
  959.      cendental functions like Sin or Exp. As the Dhrystone numbers, the
  960.      results of the Whetstone benchmark depend as much on the hardware
  961.      as on the code quality of the compiler (whether optimizing or not),
  962.      although the compiler dependency is usually somewhat less than with
  963.      the Dhrystone benchmark. Therefore, Whetstone numbers as determined
  964.      by COMPTEST should not be compared to those determined by other programs.
  965.      To make Whetstone results useful, the performance is also rated in
  966.      comparison with the original IBM-PC. Note that the test uses software
  967.      emulation of the coprocessor if the machine tested does not have
  968.      an 80x87 mathematical coprocessor, and that in this case the performance
  969.      is compared to the equivalent PC configuration, that is a PC without
  970.      an 8087. There are two versions of the Whetstone benchmark, an older
  971.      version derived from the original article published in 1976 and a newer
  972.      version that includes sanity checks. The latest available version
  973.      acquired from one of the original authors (Brian Wichmann) is used here.
  974.  
  975.  
  976. o    MFLOPS:
  977.      This benchmark result tells you how many millions of basic floating
  978.      point operations (add, subtract, multiply) the tested machine is able
  979.      to execute per second. This number is determined by running an older
  980.      version of the Lawrence Livermoore Loops, a set of 14 kernels taken
  981.      from *real* number crunching programs and computing the average MFLOPS
  982.      (Millions of FLoating-point OPerations per Second). There is a newer
  983.      suite of LLL out that uses 24 kernels and provides more detailed
  984.      diagnostics of the floating point performance. Due to its size, it
  985.      could not easily be integrated into COMPTEST, so the older (and simpler)
  986.      version was used. The LLL benchmark uses about 60 KB of RAM, so results
  987.      may be influenced by the size of the CPU cache, if any is installed.
  988.      For reference, the MFLOPS are compared to the performance of an IBM-PC
  989.      with 8087 (if the tested machine also has a coprocessor) or to a plain
  990.      IBM-PC using the software emulator (if the machine tested does *not*
  991.      have a coprocessor). As with the other benchmarks, the LLL performance
  992.      depends not only on the hardware, but also on the compiler used. Highly
  993.      optimizing compilers that make use of 32-bit instructions where possible
  994.      would give an MFLOPS rating that is about 50% higher.
  995.  
  996.  
  997. o    Hard disk data:
  998.      COMPTEST usually is able to test all hard disks in your system, regard-
  999.      less of whether they use the ST506, IDE, ESDI, or SCSI interface. How-
  1000.      ever, it may fail to detect some special types of hard disks like the
  1001.      removable data packs found on some Tandon computers that use special
  1002.      drivers to hook into the DOS file system.
  1003.  
  1004.  
  1005. o    Hard disk geometry (# cylinders, # read/write heads, sectors per track):
  1006.      These disk parameters are given as reported by the BIOS. The parameters
  1007.      given may not reflect the physical geometry of the disk. For example,
  1008.      if a disks uses the zone bit recording technique, there is no
  1009.      fixed ratio of sectors per track, rather the number of sectors per
  1010.      track is greater in the outer zones and smaller in the inner zones.
  1011.      So the parameters given reflect the logical layout of the disk as
  1012.      seen by the BIOS, which may or may not coincide with the physical
  1013.      layout of the disk.
  1014.  
  1015.  
  1016. o    Hard disk storage capacity:
  1017.      The *formatted* capacity of the disk is given in bytes and MB. Note
  1018.      that a MB contains 1024x1024 = 1,048,576 bytes if computed correctly.
  1019.      Some disk manufacturers (e.g. Quantum) state the storage capacity in
  1020.      MBs consisting of only 1,000,000 bytes. Therefore, the capacity in MB
  1021.      as reported by COMPTEST may be lower than the capacity the manufacturer
  1022.      claims for the disk. Also, the capacity you can use using DOS may be
  1023.      even smaller, since DOS allocates some disk memory to build allocation
  1024.      structures like partition tables or FATs.
  1025.  
  1026.  
  1027. o    Track-to-track seek time:
  1028.      The time it takes to move the read/write heads of your hard disks
  1029.      from one cylinder to an adjacent cylinder. The time reported may
  1030.      be zero when using certain disk cache programs (e.g. HyperDisk),
  1031.      as these suppress unnecessary head movements if no data is read
  1032.      or written in the process (as happens when COMPTEST does this
  1033.      test). Also, COMPTEST may be fooled by the so called translation
  1034.      modes mainly used by certain hard disks using the IDE interface
  1035.      to overcome limitations to the maximum number of cylinders set
  1036.      by the BIOS or to accommodate the fixed sectors/track scheme of
  1037.      PCs to the modern zone bit recording technique. With translation
  1038.      mode enabled, two logical tracks can reside on the same physical
  1039.      track, essentially nullifying the time to move between the logical
  1040.      tracks. COMPTEST moves the read/write heads over all tracks in single
  1041.      track steps and divides the total time by the number of tracks moved.
  1042.      This provides an average time, since movements between adjacent tracks
  1043.      may take different times depending on the absolute location of the
  1044.      tracks.
  1045.  
  1046.  
  1047. o    Average seek time:
  1048.      The time needed on the *average* to position the read/write heads
  1049.      over an arbitrarily selected cylinder on the disk. This time is
  1050.      roughly equal to the time it takes the heads to travel over one
  1051.      third the total numbers of tracks. It can be shown that, if tracks
  1052.      are selected at random from a uniform distribution on [0..MaxTrack]
  1053.      the average difference between any pair of track numbers is equal
  1054.      to one third the total numbers of tracks. Note however, that the
  1055.      assumption of a uniform distribution in track access patterns
  1056.      usually does *not* hold for practical file systems. Also, the
  1057.      average number of tracks traveled by read/write heads varies
  1058.      for the different zones of a disk using zone bit recording or
  1059.      using read/write queuing. For most disks however, the number
  1060.      reported by COMPTEST should be close to the number stated by the
  1061.      disk's manufacturer. When using certain disk cache programs, you
  1062.      will see very small times due to the fact that these programs
  1063.      suppress all unnecessary head movements. Note also that the
  1064.      average access time by definition is not equal to the tine needed
  1065.      on the average to access a specific sector on the disk. For this
  1066.      you have to add at least the rotational latency (the time needed
  1067.      until the read/write head reaches the designated sector on the
  1068.      track after having moved to the correct cylinder). This takes
  1069.      half of the time required for a full revolution of the disk in the
  1070.      average case, that is 8 ms for a disk spinning at 3600 rpm. Newer
  1071.      disks often spin at a higher speed of 4400 rpm or more to reduce
  1072.      rotational latency.
  1073.  
  1074.  
  1075. o    maximum throughput:
  1076.      COMPTEST determines the maximum throughput of a disk similar to the
  1077.      well known CORETEST disk test program by repeatedly reading the
  1078.      same block from disk. It uses the low level functions provided by
  1079.      the BIOS to maximize performance. The amount of data read is the
  1080.      data on one cylinder or 63 KBytes, whichever is smaller. Therefore,
  1081.      no movement of the read/write heads occurs during the read test.
  1082.      The disk's read throughput is determined for the first and the last
  1083.      cylinder on the disk. For hard disks using the zone bit recording
  1084.      technique, the throughput on the outermost cylinder can be about 50%
  1085.      higher than on the innermost cylinder, since more data is recorded
  1086.      on the outer cylinders. Since COMPTEST reports the maximum throughput,
  1087.      it always reports the higher of the two transfer rates it determines.
  1088.      The transfer rate in real applications is usually much lower than
  1089.      the maximum transfer rate reported by COMPTEST. By repeatedly reading
  1090.      the same block from disk, COMPTEST causes the block to be read into
  1091.      the track buffers and on-disk hardware caches present on most modern
  1092.      disks or the cache memory of a caching controller. If the block fits
  1093.      completely into such a cache, the transfer rate measured is actually
  1094.      the transfer rate between the buffer/cache and the system memory. A
  1095.      more realistic transfer rate could be determined by completely reading
  1096.      the data on several adjacent tracks. Since every data item is read
  1097.      only once, a cache will not inflate the transfer rate. The transfer
  1098.      rate determined by this process is called the linear read rate. It
  1099.      is used to measure disk performance in programs such as PCTOOLS 7.1's
  1100.      SI. The linear read rate can be useful to determine disk performance
  1101.      for operations on large files that are contiguous and are read
  1102.      sequentially with only a small amount of head movement. Many applications
  1103.      use random access files, though, and files may not be stored in
  1104.      contiguous form on the disk. In these circumstances, there is a
  1105.      considerable amount of head movement and the seek time and rotational
  1106.      latency cause overhead that further reduces the effective transfer
  1107.      rate available to applications. Note that COMPTEST uses the BIOS to
  1108.      access the disk, while applications make use of an operating system's
  1109.      file system that introduces additional overhead. Also, write access
  1110.      to a disk may be significantly slower than read accesses. Hardware
  1111.      caches on the disk or on the disk controller and software caches
  1112.      like HYPERDISK and SMARTDRV can provide better disk performance
  1113.      by storing frequently used data in cache memory that can be accessed
  1114.      faster than the disk itself. COMPTEST tries to determine the presence
  1115.      of a disk cache by repeatedly reading a small amount of data from
  1116.      different (non-adjacent) tracks. If no cache is present, the head
  1117.      movement to access the different tracks is the reason that the read
  1118.      time can not fall below a certain level due to the physical limits
  1119.      that prevent a reduction in average seek times below about 12 ms.
  1120.      If a cache is present, all data can be hold in the cache memory
  1121.      after the first read access and no additional head movements take
  1122.      place, thereby causing fast execution of COMPTEST's test to determine
  1123.      presence of a disk cache. COMPTEST does not differentiate between
  1124.      hardware and software caches.
  1125.